In a computer interface, the aim of the various types of menu is to navigate through the various pages of the interface or MMI (Man Machine Interface) or to perform a specific action.
Numerous applications use menus made up of trigger elements for implementing actions linked to these trigger elements. Notably, a trigger element of a menu allows triggering either of processing on a datum or a previously selected content or of access to one or more data or content, etc.
The menus may be predefined: the list of trigger elements or commands does not vary and therefore remains fixed throughout the interface. There are also what are known as contextual menus in which the list of commands is variable and opens when the user selects, in a specific manner, a point on the interface thus providing a list of commands that varies according to the targeted point. Most often, the user triggers these menus using the secondary button (called right clicking) of the mouse.
As the applications evolve and offer more and more services: processing with access to a large number of data, content, etc., the number of lists of trigger elements and of trigger elements of the menus increases. This growing number of trigger elements gives rise to additional difficulties for the user of the application, who gets lost in finding processing operations for which he wishes to control the execution or the data, content which they wish to access.
For this reason, the applications often offer menus with shortened lists of trigger elements made up of a fixed subset of the trigger elements of the global list. This subset is notably made up of the trigger elements that are used most commonly in the previous version of the application by all of the users. In this case, on a given version of an application, the menus remain predefined.
Possibly, the menus may be personalizable by the user, who himself adds or removes a trigger element to/from a pre-existing list. These personalizable menus nevertheless remain fixed between two instances of use of the application. Two difficulties arise in this manual personalization:                first is the difficulty in the actual choice owing to the large number of trigger elements that are generally available: difficulty in locating the trigger elements that could be useful to the user, difficulty in understanding the contribution of each available trigger element, etc.        the second lies in the fact that the list remains fixed in the personalization state: if it is too short it will limit use of the application; if it is too long it risks confusing the user. Moreover, if the user changes, he will have to take steps to modify the personalization at the risk of holding up his use of the application.        
Furthermore, some interfaces offer dynamic menus in which the list of commands is generated automatically and dynamically by the application following actions by the user. These are history menus such as the history of Word, which is compiled as documents are opened/closed and which offers, in its file history menu, a list of given files at an instant T and then, at an instant T+2, the same list to which will have been added a file that will have been opened at the instant T+1. This history can have the same disadvantages as the predefined menus after multiple use owing to a large number of open files, namely the difficulty of finding a file therein that is not among the last five files opened (for example).
In all of these menus, the notion of abundance or poverty of trigger elements in a list is not managed. Thus, the lists of trigger elements may be long to go through, just like drop-down menus for choosing countries, or incomplete on account of their fixed nature or in the case of manual personalization.